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(54) A method, apparatus & computer program product for dynamic administration, management 
and monitoring of daemon processes 

(57) Apparatus, methods and corrputer program 
products are disclosed that allow ta dynamic adminis- 
tration, management and nKMiitoring of daenrwn pro- 
grams executing within a computer. The invention uses 
sen^ice agent programs (315. 319) to communicate with 
a daemon program (301) that provides services for a 
resource. TTie daemon program (301) responds to 
administrative messages from the service agent The 
service agent program (315. 319) uses these adminis- 
trative messages to interact with the daemon program 
(301) to perform administrative operations on the dae- 
mon program or the resources served by the daemon 
program without requiring the daemon program to be 
terminated and restarted. 
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Description 

Background of the Invention 
5 Field of the Invention 

10001] This invention relates to the field of computer server program administration. Specifically, this invention is a 
method, apparatus and computer program product for dynamic administration, management and monitoring of daemon 
programs executing within a connputer. 

10 

Background 

[0002] Most computer operating systems indude a mechanism for executing server programs. These server-pro- 
grams are used to provide services to other, possibly networked, client-programs. These server-programs generally do 

15 not interact with a user. Instead, a client-program requests the server-program to perform an operation. The server-pro- 
gram performs the requested operation and generally returns a result to the dient-program. These server-programs are 
commonly refenred to as "daemon" programs and are subsequently defined. The daemon program is often invoked 
when the operating system initializes. When the daemon program starts execution, it may access command line options 
and/or read a preference or initialization file to further configure its operation. Daemon programs often provide services 

20 that are similar to operating system services. One example of a daemon program is a program that provides file opening 
and closing services for file resources. Another example of a daemon program is an HTTP server program that provides 
World Wide Web (WWW) page services for web page resources over the Internet. 

[0003] Rg. 1 A illustrates a prior art daenx)n architecture, indicated by general reference character 1 00. for providing 
services for one or more resources. This example uses an HTTP server daemon program 101 within the prior art dae- 

25 mon archrtecture 100. The HTTP server daerrxxi program 101 accesses a preference file 103 to obtain information 
about the resources that it serves. The prior art daemon architecture 100 also includes a connection to a network 1 05. 
The communication through the network may be. but need not be, totally contained within the computer hosting the 
HTTP server daemon program 101. The HTTP server daemon program 101 provides service for multiple WWW 
don^ns. These indude a first served web site 107, a second served web site 109 and a third sensed web site 1 1 1 . In 

30 this example, each of the WWW domains is a resource served by the HTTP server daemon program 1 01 . 

[0004] One problem with prior art daemon programs is that they are generally designed to begin execution soon after 
the computer's operating system is booted and to continue execution until the computer is shutdown. Thus, if the oper- 
ating characteristics for the daemon program change from the characteristics specified when the daenx)n program ini- 
tiated, the daemon program must be terminated and restarted with the new characteristics. Between the time the 

35 daemon program terminates and the time the restarted daemon program is initialized, the service provided by the dae- 
mon program is unavailable. Thus, performing administrative functions on the daemon program effects the availability 
of the sen^ices for the resources provided by the daemon program. Such administrative functions indude (without limi- 
tation) reconfiguration of the daemon program, performance tuning of the daemon program, and performance rrxjnitor- 
ing of the daennon program. 

40 [0005] Hg. 1 B illustrates a prior art daemon re-initialization process, indicated by general reference character 150. 
used to change the characteristics of a daenrx)n program. The prior art daemon re-initialization process 150 initiates at 
a 'start* terminal 151 and continues to a 'daemon program invocation' step 153. As was previously desaibed, the dae- 
rTX>n program can be invoked by a system administrator who may specify invocation options. OrKe the daenrx)n program 
is invoked, it Initializes itself (possik)ly using command line options and/or information contained in a preference file) and 

45 provides services at a lirst daenrwn program execution* step 1 55. The administrator then deddes to change the opera- 
tion of the daemon program. To do sa the system administrator edits the preferer^e file if required Of the desired 
changes can be accomplished simply by changing startup optk)ns this step is not necessary) at an 'edit preferences' 
step 157. Next the system administrator initiates a terminate daemon program* step 159 that terminates the daenxxi 
program. Once the daemon program terminates, the services for the resources provKled by the daerTK)n program are 

so no longer available to client-programs. Next, at a 'daemon program re-invocation' step 161 . the system administrator 
restarts the daemon program using different command line options and/or the preference file edited t>y the 'edit prefer- 
ences* step 1 57. Thus, a *secorxj daemon program execution' step 163 begins execution using the new options and/or 
preference file snd so operates differently than the lirst daerrxMi program execution' step 1 55. The prior art daerrx^n re- 
initialization process 150 completes at an 'end* terminal 165. 

55 [0006] Some daemon programs provide services for nuitipte resources. One example of such a daenxxi program is 
an HTTP daenfK>n program. For exarrple. a typteal HTTP daenrxjn program supports multiple WWW sites. If the execu- 
tion of the HTTP server daenrx)n program is terminated to nxxlify a parameter for one of the served WWW sites (for 
exanrple. by using the process of Fig. 1 B). service for ail the served WWW sites will be intemipted until the HTTP dae- 
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mon program is restarted. 

[0007] These daemon programs need a more efficient mechanism to allow an administrator to control the operation 
of the daemon programs. l=or example, a WWW server administrator needs the ability to change access control options, 
to enable particular domains and to gather data for monitoring the performance of the daemon program. In the prior art. 
5 the daemon program generally stores performance and status information in a file. The administrator often needs to ter- 
minate the daemon program to get access to all the information in the file. 

[0008] Thus, one problem is that the administration of daemon programs causes interruptions to the sen^ices for 
resources provided by the daemon programs. This service inten-uption affects the users of programs served by the dae- 
mon programs. This service interruption also generally requires administration of the daemon programs to be per- 
70 formed when the daemon programs are least utilized — generally at times that are inconvenient to the administrator. 
[0009] It would be advantageous to provide a method, apparatus and program product that allow administration of a 
daemon program without requiring that the daemon program be completely disabled during the administration process. 
Such an Invention improves the perfbnmance of computer systems by reducing the amount of time that sen^ices to 
resources are unavailat)le because of administrative functions. 



Summary of the Invention 

[001 0] The invention is defined in daims 1 , 9, 1 7 and 25, respectively Particular embodiments of the invention are set 
out in the dependent dainr^. 

20 [001 1 1 The present invention inrproves the administration of daemon progranns by providing a mechanism to perform 
administrative functions on the daemon programs without terminating the services provided by the daemon programs 
to the serviced resources. 

[001 2] One aspect of the invention is a computer controlled method for dynamically performing a control operation on 
a daemon program. The daemon program provides a service for one or wore resources. The method indudes the step 
25 of registering the daemon program with an inter-process communication mechanism. Another step is ttwit of connecting 
a service agent program to the daemon program using the inter-process communication mechanism. The method also 
sends a message from the service agent program to the daenion program using the inter-process communication 
mechanism. Yet another step is that of processing the message by the daemon program performing the control opera- 
tion. 

30 [001 3] Another aspect of the invention is an apparatus, having a central processing unit (CPU) and a memory coupled 
to the CPU. for dyriamically pertonming a control operation on a daemon program. The daenron program provides a 
service for a one or more resources. The apparatus includes a registration medianism that is configured to register the 
daenron program with an inter-process comnrujnication mechanism. It also indudes a connection mechanism that is 
configured to connect the service agent program to the daemon program using the inter-process conrvnunication mech- 

35 anism. The apparatus also indudes a message mechanism that is configured to send a message from the service 
agent program to the daemon program using the inter-process communication mechanism. In addition, the apparatus 
indudes a processing mechanism that is configured to process the message by the daemon program. 
[0014] Yet a further aspect of the invention is a computer program product enrtxxlied on a computer usable medium 
fa causing a computer to dynamically perfomn a control operation on a daemon program. The daenrwn program pro- 

40 vides a service for one or more resources. When executed on a computer, the computer readable code causes a com- 
puter to effect a registration mechanism, a connection mechanism, a message mechanism and a processing 
mechanism. Each of these mechanisms having the same functions as tiie corresporKling mechanisms for the previ- 
ously desaibed apparatus. 

[0015] An additional aspect of the invention is conrputer program product embodied in a earner wave. The carrier 
45 wave transmits computer readable code therein for causing a conputer to dynamically perform a conti-ol operation on 
a daennon program. The daemon program provides a service for one or niore resources. When executed on a compu- 
ter, the computer readat)le code causes a computer to effect a registration mechanism, a connection mechanism, a 
message mechanism and a processing mechanism. Each of these n^echanisms having the same functions as the cor- 
responding mechanisms for the previously described apparatus. 
50 (001 6] The foregoing arx) many other aspects of the present invention will no doubt become obvious to those of ordi- 
nary skin in the art after having read the fdlowing detailed description of tiie preferred embodiments that are illustrated 
in the various drawing figures. 
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55 



(00171 



Fig. 1 A illustrates a prior art daennon architecture: 
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Fig. 1 B illustrates a prior art daemon re-initialization process: 

Fig. 2 illustrates a computer system capable of using the invention in accordance with a preferred en^xxjiment; 
Fig. 3 illustrates daenron program architecture in accordance with a preferred embodiment: 
Fig. 4 illustrates the operation of a daemon program in accordance with a preferred embodiment: 
Fig. 5 illustrates the operation of an agent program in accordance with a preferred embodiment: 
Fig. 6A Illustrates the operation of an administrative-services client program in accordance with a preferred embod- 
iment: and 

Fig. 6B illustrates the operation of a network manager programs in accordance with a preferred embodiment. 



10 Description of the Preferr ed Embodiments 



Notations and Nomenclature 



[001 8] The following 'notations and nomenclature' are provided to assist In the understanding of the present invention 

15 and the preferred embodinnerrts thereof. 

[0019] Control operation — A control operation is any operation that is ancillary to the main function of the daemon 
program. A control operation Includes (without limitation) an administrative operation, a configuration operation, a sta- 
tus operation, and a performance monitoring operation. The control operation may be directed toward the daemon pro- 
gram or one or nrtore of the resources served by the daemon program. 

20 [0020] Daemon program — A daemon program is a program that runs continuously and autonrtatically in the back- 
ground (Wired Style; Principles of English Usage in the Digital Age, © 1 996 by Hardwired, page 44. ISBN 1 -888869- 
01-1). Another definition is a process that performs a utility functbn without user interaction (Inside OS/2, © 1988 
Microsoft Press, page 270, ISBN 1 -5561 5-1 17-9). Most UNIX-like systems have daemon programs that provide print 
services, rennote file services, and Internet services along with many other services. Similar functionality is provided 

25 (often using a different terminology) by other operating systems. 

[0021] Procedure — A procedure is a self -consistent sequence of steps leading to a desired result These steps are 
those requiring physical manipulation of physical quantities. Usually these quantities take the form of electrical or mag- 
netic signals capable of being stored, transferred, combined, compared, and othenmse manipulated. These signals are 
referred to as bits, values, elements, synrbols, characters, terms, numbers, or the like. It will be understood by those 

30 skilled In the art that ail of these and similar terms are associated with the appropriate physical quantities and are 
merely convenient labels applied to these quantities. 



Operating Environment 



35 [0022] The invention uses a computer. Some of the elements of a computer, as Indicated by general reference char- 
acter 200. configured to support the invention are shown In Rg. 2 wherein a processa 201 is shown, having a central 
processor unit (CPU) 203, a menrtory section 205 and an Input/output (I/O) section 207. TTie I/O section 207 is con- 
nected to a keyboard 209, a display unit 211 . a disk storage unit 21 3 and a CD-ROM drive unit 215. Ttie CD-ROM drive 
unit 21 5 can read a CD-ROM medium 217 that typically contains a program and data 219. The CD-ROM drive unit 21 5, 
40 akmg with the CD-f^M medium 217 and the disk storage unit 213 comprise a fllestorage mechanism. The computer 
system also includes a network inteftace 221 that connects the computer system to a network 223. Such a computer 
system is capable of executing applications that entxxiy the invention. One skilled in the art will understand that the 
network can be used to communicate between separate programs within the same computer using network-t>ased 
mechanisms. Thus, the communcation t>etween programs within the computer system need not actually extend out- 
45 skie of the computer system ever the network 223. One skilled in the art will understand that some embodiments of the 
invention can t>e implen^nted on a computer having only a sii>set of the atx)ve capabilities. 
[0023] A preferred embodiment shown in Rg. 3, iNustrates a daenx)n program architecture, indkated by general ref- 
erence ctiaracter 300, which incorporates the inventk>n with an HTTP server daenxxi progrEim 301 . On initialization, the 
HTTP server daemon program 301 accesses a preference ffle 303 to obtain its startup oonfigifation (possisly in con- 
so junction with convnand line optk)ns). The HTTP server daenx)n program 301 binds to a network 305 and provides con- 
current HTTP services to resources such as a first served web site 307, a second served web site 309. and a third 
sensed web site 311. The HTTP server daemon program 301 also includes an inter-process convTUjnication mecha- 
nism 313 that allows an agent program to comnxjnicate to the HTTP server daemon program 301 . An 'administrative 
sennces agent* program 31 5 communicates over the network 305 to an 'administratkxi client* program 31 7. The *admin- 
55 istration client* program 31 7 sends requests for administrative operatk>ns to the 'administrative servk^es agent* program 
315 that then performs the requested operation. To perform the requested operation, the 'administrative services agent' 
program 31 5 may change the preference file 303 or communicate with the HTTP sender daenxxi program 301 using the 
inter-process communication mechanism 31 3. tf the 'administrative services agent* program 31 5 communicated to the 
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HTTP server daemon program 301 . the HTTP server daerTX)n program 301 performs the requested operation and 
acknowledges the status of the completion of the requested operation to the 'administrative services agent' program 
315 (possibly returning other information). This infamation is then returned to the 'administration client' program 317. 
A similar process occurs using a 'SNMP agent' program 319. However, in this case a 'network nrianager service' pro- 

5 gram 321 communicates over the network 305 using the SNMP protocol to the *SNMP agent' program 31 9, which then 
communicates to the HTTP server daemon program 301 to perform the requested operation. In addition, a 'command 
line interface' program 323 may connect to the HTTP server daemon program 301 using the inter-process communica- 
tion mechanism 31 3. The 'comnr^nd line interface' program 323 allows textual commands to be sent to the HTTP server 
daemon program 301 as required. 

10 [0024] One advantage of the daenrion program architecture 300 is that the HTTP server daenrron program 301 can 
receive, process, and respond to. commands through the inter-process communication mechanism 313. Thus, the 
administrative services agent' program 315 can reconfigure the preference file 303 (for exarrple nxxlifying parameters 
for the first served web site 307) and then communicate with the HTTP server daenron program 301 to restart service 
for the first served web site 307 using the new parameters. Thus, the HTTP server daemon program 301 can modify 

15 the first served web site 307 without interrupting service to the second served web site 309. This allows a network 
administrator to selectively enable or disable services for a particular domain without affecting services provided to 
other domains. 

[0025] In addition, the HTTP server daemon program 301 can provkle status information to the 'administration client' 
program 317 in a similar manner. The 'administration client' program 317 sends a status request over the network 305 

20 to the 'administrative services agent' program 315. The 'administrative servkies agent' program 315 converts the 
request to one or more communications, using the inter-process communication mechanism 313. to the HTTP server 
daenrwn program 301 . The HTTP server daenrron program 301 processes and responds to these communications to 
provkje status information to the 'administrative services agent' program 315. The 'administrative services agent' pro- 
gram 315 then assembles the returned information and sends the assembled data to the 'administration client' program 

25 317. 

[0026] One skilled in the art will understand that daemon programs that provide services other than HTTP services 
also benefit from the invention. Examples (without limitatwn) of such daemon programs include an FTP daemon, an e- 
mail daemon, a Usenet news daemon, a system log daemon, a directory services daemon and an Internet standard 
services daemon. One skilled in the art will understand that daemon programs other then those listed will also benefit 
30 from the invention. 

[0027] The inter-process communication mechanism 313 used by the invention can be based on any inter-process 
communication mechanism. These mechanisms include inter-process communication (IPC) mechanisms such as 
(without limitation) Solaris^ Doors, pipes, senr«phores. shared memory, queues, signals, and mailboxes, and message 
queues. These mechanisms also include (without limitatkMi) remote procedure call (RPC) mechanisms, TCP/IP mech- 

35 anisms. and renrwte method invocation (RMI) mechanisms. One skilled in the art will uKlerstand that many mecha- 
nisms exist to pass information between programs executing within a computer. The invention contemplates the use of 
any such Inter-process communication mechanism that can provkle the capability for a sen^ice agent program to 
access the sender program. A preferred embodiment of the inter-process communication mechanism provdes security 
such that only a known trusted service agent program may access the daemon program. A preferred embodiment uses 

40 the Solaris Doors mecfianism. 

[0028] The 'administrative sennces agent* program 315 and the *SNMP agent' program 319 are each an exanple of 
a service agent program. The service agent program prcvkies an interface between the network 305 and a daemon 
program such as the HTTP server daemon program 301 for administrative services. Each service agent program 
makes a trusted connection with the daemon program. Each servk;e agent program also makes itself available as a 

45 service over the network. The service agent program receives commands from a networked program and performs the 
appropriate conrvnunications to the daenx)n program to satisfy the command. The results are returned to the service 
agent program from the daenrx>n program that, in tum, sends the results t>ack to the networked program that initiated 
the request Example sendee agent programs include (without limitation) a SNMP agent, an FTP administratk>n agent, 
and a WWW sender administration agent The invention contemplates the use of sennce agent programs other than 

so ttK>se just listed. 

[0029] One skilled in the art will understand that many techniques exist for programs to comnxinicate over a network. 
These techniques include well known TCP/IP protocols or HTTP protocols. Such a one will also understand tfiat WWW 
page services generally use an HTTP daemon program to process the HTTP protocols. Thus, if the service agent pro- 
gram is sen/k^ed by the HTTP server daenfK>n program 301 thedata flow indrcated in the example illustrated by Fig. 3 
55 is nxxjif ied so that commands from the client programs first pass through the HTTP server daeoKxi program 301 . 
[0030] Hg. 4 illustrates a daemon program process, Indicated by general reference character 400, for providing serv- 
ices to resources. The daemon program process 400 is generally invoked as a result of an operator inputting an explicit 
command to the computer system, as a result of an automatic tnvocatkxi from the system's initializatk)n process or as 
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a result of a timer event. The invocation of the daemon program may include processing commarxJ line options that 
specify various operational parameters to the daemon program. The daemon program process 400 initiates at a 'start' 
terminal 401 and continues to a 'daemon initialization' procedure 405. The 'daemon initialization' procedure 405 gener- 
ally performs, for example, storage initialization, creation of additional threads-of- execution and other initialization oper- 

5 ations that are well understood by the art. Next, the daemon program continues to a process preferences* procedure 
407 that reads and processes the contents of the preference file 303 ar»d processes any command line options. The 
preference file 303 contains information that allows the daemon program to reconfigure itself to the same condition as 
when the daenwn program last terminated. For the HTTP server daemon program 301 , the preference file 303 contains 
information that identifies the web sites 307. 309. 31 1 that are the resources serviced by the daemon program. 

; 0 (0031 J Then, the daenron program process 400 continues to a 'register with inter-process communication mechanism' 
procedure 409 that enables future communication from at least one service agent program, (for example, the adminis- 
trative services agent' program 315) through the inter-process communication mechanism 313. The register with inter- 
process communication mechanism' procedure 409 depends on the details of the inter-process communication mech- 
anism 313 implementation. The registration process generally includes: registering server program identification infor- 

/5 mation; specifying security options (to limit communications to the server program by trusted service agent programs); 
and performing other operations to ready the daemon program for receiving communications from a service agent pro- 
gram. 

[0032] The daemon program process 400 (in a preferred embodiment) then creates another thread-of-execution so 
that one thread-of-execution is used to support a 'provide daemon sen^ices' procedure 411 that provides the services 

20 to resources supported by the daemon program. The 'provide daenrion services* procedure 41 1 may itsetf spawn addi- 
tional threads as required to provide the daeown program's services. The other thread-of-execution is used to process 
requests from each sen/ice agent program. One skilled in the art will understand how to use threads-of-execution to 
perform multiple operations within the same program. A Vrart for agent message' procedure 41 3 waits for a command 
to be received by the inter-process communication mechanism 313. When a command is received, the process contin- 

25 ues to a 'receive agent message' procedure 41 5. In a preferred embodiment, another thread is spawned to process the 
command by a "program agent message' procedure 417. The 'program agent message' procedure 417 uses an 'inter- 
thread communication' mechanism 41 9 to affect execution of the "provide daenrK)n services' procedure 41 1 responsive 
to the received messages. The 'inter-thread communication' mechanism 419 may use thread mutexs. condition varia- 
bles or other well-known techniques to obtain Information from, and perform administrative operations on. the 'provide 

30 daemon services' procedure 41 1 . Once the requested operation is completed, an 'acknowledge agent message' pro- 
cedure 421 acknowledges to the appropriate sen/ice agent program that the comnr^nd was completed, the status of 
the command completion and any additional data required by the service agent program. The program then ends the 
execution of the thread arxl returns to the "wait for agent message' procedure 413 to receive the next command. 
[0033] Fig. 5 illustrates an 'agent execution' process, indicated by general reference character 500, for connecting a 

35 networked application to the daenDon program. The process 500 is generally initiated by an operator inputting an explicit 
command to the computer system, an automatic invocation from the system's initialization process or because of a 
timer event. This process is implemented by both the 'administrative services agent' program 31 5 and the 'SNMP agent' 
program 319. The invocation of the process 500 may include processing convnand line option that specify various con- 
ditions to the agent program. Once invoked, the process 500 initiates at a 'start' terminal 501 and continues to a 'startup 

40 initialization' procedure 503 that initializes the agent program. Next, the process 500 continues to a 'connect with dae- 
mon' procedure 505 that accesses the inter-process confimunication mechanism 313 to determine whether the desired 
daemon program has registered (see the 'register wrth Inter-process communication mechanism' procedure 409). If the 
desired daemon program has not registered, the agent program may retry after some delay or provide an error indica- 
tion. However, H the desired daenfx>n program has registered, the servrce agent program opens a connection with the 

45 daemon program using the inter-process communication mechanism 31 3. 

[0034] Next, the process 500 continues to a bind with network* procedure 507 that establishes the presence of the 
sendee agent program on the network. The Ijind with network* procedure 507 uses well-known techniques to register 
with the network protocols. For example, with a TCP/IP networic, the program may be associated with a specific URL. 
or have a known TCP/IP socket and port 

so [0035] At this point, the service agent program has completed initialization and waits to receive a command. Eventu- 
ally, at a 'receive CMD from networked administration client' procedure 509, the process 500 receives a command from 
the network. The process 500 parses and processes the command at an 'agent specific CMD processing' procedure 
510. Then the process 500 generates and sends an appropriate message or sequence of messages specifying a con- 
trol operation to the daemon program at a 'send control operation to daemon* procedure 511 to effectuate the com- 

55 mand. The daemon program responds by processing the message and perfomning the specified control operation and 
returns a result and Crf required) data. The control operation may be directed toward the daemon program Itsetf or one 
or mae of the resources controlled by the daemon program. Some example control operations are (wittxHit limitation) 
those that cause the daemon program to re-initiaf ize. suspend service of a resource, provide performance Information 
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and other useful operations as may be desired. Eventually, the daemon program performs the requested operation and 
returns a result to the process 500 at a 'receive result from daemon' procedure 513. Once the process 500 receives 
information from the daemon program, an 'agent specific result processing' procedure 514 processes the results 
according to the specrficattons of the service agent program. Then a 'send results to networked administration client* 

£ procedure 51 5 sends the results to the network dient. 

[0036] Fig. 6A illustrates an *administrative-sen/ices client' process, indicated by general reference character 600 that 
communicates with the 'administrative services agent' program 315 that implements the process 500 shown in Fig. 5 to 
allow a trusted user to perform administrative functions on the daenrton program. The 'administrative-services client' 
process 600 is generally implemented by the 'administration client' program 317. The 'administrative-services client' 

10 process 600 initiates at a 'start' terminal 601 and continues to a 'connect with admin, services agent' procedure 603 that 
uses a network protocol (for example, TCP/IP) to establish a connection with the 'administrative services agent' pro- 
gram 315. Once the connection is estatHished. the 'administrative services agent' program 315 verifies that the user is 
a trusted user at a Verity user' procedure 605. Once the user is verified as a trusted user, the administrative-services 
client* process 600 continues to an 'otrtain selected administrative function' procedure 607 that presents the user with 

15 a selectbn of functions. The user selects a function that specifies a control operation. This control operation is then sub- 
mitted to the ^administrative services agent' program 315 where it is processed in accordance with the process 500 
shown in Fig. 5. Eventually, the 'administrative-services client' process 600 receives a response from the 'administrative 
services agent" program 31 5 at a 'receive response from agent' procedure 61 1 . This response is processed by a 'proc- 
ess response' procedure 61 3, The processed response generally indicates to the trusted user that the desired function 

20 has completed. The 'process response' procedure 61 3 also displays to the user any information returned by the 'admin- 
istrative services agent' program 315. Then the 'administrative-services client* process 600 continues back to the 'con- 
nect with admin, services agent' procedure 603 to perform additional functions. 

[0037] Rg. 6B illustrates a 'network manager service client' process, indicated by general reference character 650, 
that communicates with the 'SNMP agent' program 319 that implements the process 500 shown in Fig. 5 to allow the 

25 'network manager service client' process 650 to obtain information from the daemon program. The 'network manager 
service client' process 650 initiates at a 'start' terminal 651 and continues to a 'connect with SNMP agent' procedure 
653. The 'connect with SNMP agent' procedure 653 connects with the 'SNMP agent' program 319. Then, the 'network 
manager service client' process 650 continues to a Verify network n^nagement service' procedure 655 that cooperates 
with the 'SNMP agent' program 31 9 to determine whether the 'network manager service' program 321 is trusted by the 

30 'SNMP agent' program 319. If the 'SNMP agent' program 319 does not trust the 'network nnanager service' program 
321. the 'network manager service client' process 650 indicates an error condition. Otherwise the 'network manager 
service dient' process 650 continues to a send SNMP comn^nd (control operation)' procedure 657 that uses the 
SNMP protocol to send a network management request to the 'SNMP agent' program 319. The 'SNMP agent' program 
319 processes the network management request and generates messages to the daemon program as discussed with 

35 respect to Fig. 5. The 'SNMP agent' program 319 also sends a status response and possibly results back to the 'net- 
work nr^nager service' program 321 . This response is received at a 'receive response from agent' procedure 659. Then 
the 'network manager service dient' process 650 operates on the response at a 'process response' procedure 661 as 
is appropriate. The 'network manager service dient' process 650 then continues to the 'connect with SNMP agent' pro- 
cedure 653 to submit additional SNMP requests to the 'SNMP agent' program 319. 



Library functions: 

[0038] Examples of library functions that use the Sdaris Doors facility to communicate between the agents and the 
daemon program are now provided. 
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int 

ht tpd_cal l_ins t ance ( 

char * ins t_naine , 

door_ciiid_t *C3nd, 
door_res_t **res_p, 
int *rsize_p 

) 

Table 1 



[0039] The core function that passes information to or from the HTTP daemon program is shown in Table 1 . This func- 
tion invokes a door call to the daemon program from the service agent program. The inst_name argument is used to 
so pass the name of the door registered by the daenr»on program. The cmd argument is used to pass a command code to 
the daenron program that instructs the daenron program to perform an administrative or command function. The resjp 
argument receives a pointer to the buffer allocated by the daenrton program (if any) that is used to return result data. 
The rsize_p argument receives the size of the allocated txjffer. 

int 

httpd_restart_instance (char *inst_|iame) 
{ 

int retval, rsize; 

dcx>r.cni4-t cmd; 
door_res_t * resp- 
ond. cmdName = TPD_RESTARTINST; 
retval = httpcLcall_instance( 

instjame, &ciad, &reS/ &rsize) ; 

return (retval >=0 ? SUCCESS : DOORFAILED) ; 

} 

Table 2 

[0040] The HTTP daemon program can be restarted using code shown in Table 2. Here the cnxj.cmdName is set to 
50 TPD^RESTARTINST. The inst^name argument is used to pass the name of the door registered by the daemon pro- 
gram. When the httpd_calljnstance is invoked, the oommarxJ is sent to the daenrx)n program causing the daenK)n pro- 
gram terminate services to the served resources. That is. the HTTP daemon program stops serving the WWW 
donfiains, reinitializes itself according to the preference file and resumes services to the served resources. Once the 
HTTP daenrK)n program conrpletes the restart operation, it sends a status result back to the invoking program. 
55 [0041] The HTTP daenrx>n program can be instructed to update its access control configuration as shown in Table 3. 
The inst.name argument is used to provide the name of the door registered by the daemon program. In addition, the 
domain nanne (for example, the string "www.sun.com" used to identify the first served web site 307) is used to klentify 
which resource (WWW domain) is to be reloaded. The adj ile string specifies whrch access control file is to be used to 
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initialize the web site. Thus, this calling sequence is used to reinitialize a specified web site using a specitied access 
control file. 



15 



20 



25 



int 

httpd_reload_acl ( 

char * inst.name , 

char *host_nai!ie, 
char *acl_file 
) 



cnid.cmdNaine = TPD.RELOAD^CL ; 
s tr cpy ( and . ac 1 cmd . hos t_naine , hos t_name ) ; 
strcpy ( cmd . aclcmd . acl_f ile , acl.file) ; 
retval = httpd^call_instance( 

inst.name, ftcmd, &res, trsize) ; 

return (retval >- 0 ? SUCCESS tDOORFAILED) 



table i 



30 



[0042] The HTTP daemon program can be instructed to provide dynamic statistics from the web server as shown in 
Table 4. Again, the inst_name argument is used to provide the name of the door registered by the daenxxi program. 
35 The stats argument is a pointer that will be used to access the status information returned from the daemon program. 
[0043] One skilled in the art will understarxi that the Invention provides techn'ques for 
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int 

do_get_server_stats ( 

char *Lnst_name, 
ht3tates_inst_t *3tat3 , 
) 

{ 

cmd.cmciNaine = TPD_GET_INST_STATS ; 

rbuf = (char *) &res; rsize = sizeof(res); 

retval = httpd_call_instance ( 

inst_name, ^ciod, tres, &rsize) ; 

return (retval >- 0 ? SUCCESS iDOORFAILED) 

> 

T3EI?4 

dynamic administration, management and monitoring of daemon programs executing within a computer. 

[0044] From the foregoing, it will be appreciated that the invention has (without limitation) the following advantages: 

1) The invention allows administrators to dynamically configure executing daenwn programs. For example, an 
administrator of a WWW server can reconfigure one web domain without effecting the other domains served by the 
HTTP daemon prog-am. 

2) The invention also provides a daemon architecture that allows acquisition of administrative data (such as per- 
formance data) from the daemon program v^ile the daemon program executes.: 

[0045] Although the present invention has been desaibed in terms of the presently prefen-ed embodiments, one 
skilled in the art will understand that various nrxKltfications and alterations may be made without departing from the 
scope of the invention. Accordingly, the scope of the invention is not to be limited to the particular inventon embodi- 
ments discussed herein, but should be defined only by the appended claims and equivalents thereof. 

Claims 

1 . A computer controlled method for dynamically performing a control operation on a daemon program, said daerrxxi 
program provides a service for one or more resources, said method comprising steps of: 

(a) registering said daemon program with an inter-process communication mechanism; 

(b) connecting a service agent program to said daemon program using said iriter-process communication 
mechanism; 

(c) sending a message from said service agent program to said daemon program using said inter-process 
communication mechanism; and 

(d) processing said message by said daemon program performing said control operation. 

2. The computer controlled method of claim 1 wherein step (a) further comprises: 

(a1) enabling said inter-process communication mechanism within said daenrx>n program. 

3. The computer controlled method of claim 1 wherein said control operation is selected from the group consisting of 
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an administration function, a performance monitoring function, a configuration function and a status producing 
function. 

4. The computer controlled method of claim 1 wherein said daennon program is selected from the group consisting of 
a FTP daenrwn. a mail daemon, a usenet news daemon, an HTTP daemon, a system log daemon, a directory serv- 
ices daemon and an internet standard sen/ices daennon. 

5. The computer controlled method of daim 1 wherein said service agent program is selected from the group consist- 
ing of a SNf^P agent, an FTP administration agent, and a WWW server administration agent. 

6. The computer controlled method of daim 1 wherein said inter-process communication mechanism is selected from 
the group consisting of Solaris Doors, pipes, semaphores, shared memory, queues, signals, nf^illx)xes, remote 
procedure call (RPC), arid remote method invocation (RMI). 

7. The computer controlled method of claim 1 wherein said control operation is directed toward said daemon program. 

8. The computer controlled method of claim 1 wherein said control operation is directed toward at least one of said 
one or more resources. 

9. An apparatus having a central processing unit (CPU) and a mennory coipled to said CPU for dynamically perform- 
ing a control operation on a daemon program, said daenron program provides a service for one or more resources, 
said apparatus comprises: 

a registration mechanism configured to register said daemon program with an inter-process communication 
mechanism; 

a connection mechanism configured to connect a service agent program to said daemon program, registered 
by the registration mechanism, using said inter-process communication mechanism; 

a message mechanism configured to send a message from said service agent program to said daemon pro- 
gram using said inter-process communication mechanism; and 

a processing mechanism, at said daenfx>n program, configured to process said message by said daemon pro- 
gram performing said coitrol operation. 

1 0. The apparatus of daim 9 wherein the registration mechanism further comprises: 

a comnunication setup mechanism configured to enable said inter-process communication mechanism within 
said daemon process. 

1 1 . The apparatus of daim 9 wherein said control operation is selected from the group consisting of an administration 
fuTKtion. a performance monitoring function, a configuration function and a status produdng function. 

1 2. The apparatus of daim 9 wherein said daemon program is selected from the group consisting of a FTP daennon. a 
n^il daemon, a usenet news daemon, an HTTP daemon, a system log daemon, a directory services daemon and 
an internet standard services daenr»on. 

13. The apparatus of daim 9 wherein said service agent program is selected from the group consisting of a SNMP 
agent, an FTP administration agent, and a WWW sender administration agent. 

1 4. The apparatus of claim 9 wherein said inter-process conrtmunication mechanism is selected from the group consist- 
ing of Solaris Doors, pipes, semaphores, shared meniory, queues, signals, mailboxes, remote procedure call 
(RPC), and remote method invocation (RMI). 

1 5. The apparatus of daim 9 wherein said control operation is directed toward said daemon program, 

16. The apparatus of daim 9 wherein said control operation is directed toward at least one of said one or wore 
resources. 
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1 7. A computer program product comprising: 

a computer usable storage medium having connputer readable code embodied therein for causing a computer 
to dynamically perform a control operation on a daemon program, said daemon program provides a service for 
5 one or more resources, said computer readable code comprising: 

computer readable program code configured to cause said computer to effect a registration mechanism con- 
figured to register said daemon program with an inter-process communication mechanism; 

10 computer readable program code configured to cause said computer to effect a connection mechanism con- 

figured to connect a service agent program to said daemon program, registered by the registration mechanism, 
using said inter-process communication mechanism; 

computer readable program code configured to cause said computer to effect a message mechanism conf ig- 
15 ured to send a message from said service agent program to said daemon program using said inter-process 

communication mechanism; and 

computer readable program code configured to cause said computer to effect a processing mechanism, at said 
daenron program, configured to process said message by said daemon program performing said control oper- 
20 ation. 

18. The computer program product of claim 17 wherein the registration mechanism further comprises: 

computer readable program code configured to cause said computer to effect a communication setup mecha- 
25 nism configured to enable said inter-process communication mechanism within said daemon process. 

1 9. The computer program product of claim 17 wherein said control operation is selected from the groip consisting of 
an administration function, a performance monitoring function, a configuration function and a status producing 
function. 

30 

20. The computer program product of claim 17 wherein said daemon program is selected from the group consisting of 
a FTP daemon, a mail daerrion. a usenet news daenrton, an HTTP daemon, a system log daemon, a directory serv- 
ices daemon and an internet standard services daenK)n. 

35 21 . The corrputer program product of daim 1 7 wherein said sen^ice agent program is selected from the group consist- 
ing of a SNMP agent, an FTP administration agent, and a WWW server administration agent. 

22. The computer program product of daim 1 7 wherein said inter-process communication mechanism is selected from 
the group consisting of Solaris Doors, pipes, semaphores, shared menx)ry. queues, signals, mailboxes, renrxne 

40 procedure caO (RPC), and remote product invocation (RMI). 

23. The computer program product of daim 1 7 wherein said control operation Is directed toward said daemon program. 

24. The computer program product of daim 1 7 wherein said control operation is directed toward at least one of said 
45 one or more resources 

25. A computer program product comprising: 

a computer data signal embodied in a carrier wave having computer readable code embodied therein for caus- 
so ing a computer to dynamically perform a control operation on a daenrton program, said daemon program pro- 

vides a service for one or more resources, said computer readable code comprising: 

computer readable program code configured to cause said conrputer to effect a registration mechanism con- 
figured to register said daemon program with an inter-process convnunication mechanism: 

55 

computer readable program code configured to cause said computer to effect a connection mechanism con- 
figured to connect a service agent program to said daemon program, registered by the registration mechanism, 
using said inter-process conmunication mechanism; 
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conriputer readable program code configured to cause said computer to effect a message mechanism config- 
ured to send a message from said service agent program to said daemon program using said inter-process 
communication mechanism; and 

computer readable program code configured to cause said computer to effect a processing mechanism, at said 
daemon program, configured to process said message by said daemon program performing said control oper- 
ation. 
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